Companies worldwide are actively deploying service-oriented architecture (SOA) infrastructures using web services, both in intranet and extranet environments. While web services offer many advantages over traditional alternatives (e.g., distributed objects or custom software), deploying large networks of interconnected web services can still present several challenges, particularly with respect to security and management.
Some existing SOA middleware solutions have addressed these challenges via the implementation of a policy-based security/management model. For example, Oracle Corporation's Oracle Web Services Manager (OWSM) enables companies to centrally define and store declarative policy documents (referred to herein as web service policies or policies) that describe security and/or management-related behaviors for web service clients and services in an SOA infrastructure. Each policy can be attached to one or more web service entities referred to herein as policy subjects (e.g., web service (WS) client/service endpoints hosted by one or more SOA applications). The attached policies can then be enforced at the policy subjects through configurable agents. With this model, security/management logic does not need to be hardcoded into an SOA application. Rather, such logic can be externalized in the form of a declarative web service policy, which can then be attached to a policy subject as needed by modifying metadata (referred to herein as policy attachment metadata) associated with the policy subject.
In certain implementations, policies can be attached to a policy subject via global policy attachment (GPA) metadata and/or via local policy attachment (LPA) metadata. As used herein, GPA metadata refers to one or more files that are stored in a centralized metadata store and that indirectly attach a policy with a set of policy subjects (e.g., WS client/service endpoints) by specifying a scope (e.g., domain, server, application, application port, etc.) to which the policy should apply. The scope levels can be organized in a hierarchy, with “domain” representing the highest scope level and “application port” representing the lowest scope level. The “application port” level can correspond to a specific WS client/service endpoint. This GPA mechanism is typically used by system administrators of an SOA deployment, as it allows them to attach a policy to a multitude of policy subjects in an efficient and consistent manner. Additional information regarding global policy attachments can be found in U.S. patent application Ser. No. 13/118,947, filed May 31, 2011 and entitled “ATTACHING WEB SERVICE POLICIES TO A GROUP OF POLICY SUBJECTS,” which is incorporated herein by reference in its entirety for all purposes.
As used herein, LPA metadata refers to one or more files that are stored with an SOA application and that directly attach a policy with a particular WS client/service endpoint of the application. This is logically equivalent to defining a GPA metadata file that attaches a policy to an application port. This LPA mechanism is typically used by SOA application developers, as it allows them to define security/management behaviors for the client/service endpoints of their application at design-time, and to subsequently package those behaviors (in the form of LPA metadata files) with the application.
One shortcoming with existing policy-based SOA solutions that support global and local policy attachment is that they generally apply an inflexible rule set when resolving conflicts between policies that are attached to the same policy subject via different LPA and/or GPA metadata files. This inflexibility can be problematic in several scenarios. For example, existing SOA solutions generally impose a strict rule indicating that two policies of the same type (e.g., two authentication policies) cannot be attached to a single WS client/service endpoint at the same time. Thus, when two identical policies (which necessarily are of the same type) are attached to the same policy subject (via, e.g., duplicate LPA and/or GPA metadata files), an error will always be thrown, thereby causing neither policy attachment to be recognized. This outcome may not be desirable since, in certain cases, the original intent of the individuals that created the policy attachments may have been to ensure that the policy is attached and enforced at the endpoint. The fact that the same policy was attached more than once via duplicate policy attachments may have been, e.g., an oversight or due to a lack of communication between the individuals.
As another example, existing SOA solutions generally impose a strict rule indicating that a policy attachment defined at a lower scope level always takes precedence over a conflicting policy attachment defined at a higher scope level. However, consider a scenario where (1) application developers have attached, via LPA metadata, various authentication policies to specific WS client/service endpoints (i.e., ports) of SOA applications that are deployed in an SOA environment; and (2) a system administrator of the environment wishes to define a global policy attachment that attaches a more secure authentication policy at a higher scope level (e.g., domain), thereby overriding all of the local policy attachments. With the rule described above this is not possible, since a global policy attachment defined at the scope level of “domain” can never override, or be given precedence over, conflicting local policy attachments (which are considered to be at the lowest scope level of “application port”).